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Abstract 

A  logic  simulator  can  prove  the  correctness  of  a  digital  circuit  if  it  can  be  shown  that 
only  circuits  implementing  the  system  specification  will  produce  a  particular  response 
to  a  sequence  of  simulation  commands.  This  style  of  verification  has  advantages  over 
other  proof  methods  in  being  readily  automated  and  requiring  less  attention  to  the 
low-level  details  of  the  design.  It  has  advantages  over  other  approaches  to  simulation 
in  providing  more  reliable  results,  often  at  a  comparable  cost. 

This  paper  presents  the  theoretical  foundations  of  several  related  approaches  to 
circuit  verification  based  on  logic  simulation.  These  approaches  exploit  the  three- 
valued  modeling  capability  found  in  most  logic  simulators,  where  the  third  value  X 
indicates  a  signal  with  unknown  digital  value.  Although  the  circuit  verification  problem 
is  NP-hard  as  measured  in  the  size  of  the  circuit  description,  several  techniques  can 
reduce  the  simulation  complexity  to  a  manageable  level  for  many  practical  circuits. 


1  Introduction 


Logic  simulators  provide  a  valuable  tool  for  testing  the  correctness  of  digital  circuits. 
Typically,  however,  only  a  limited  set  of  test  cases  is  simulated,  and  the  circuit  is  presumed 
correct  if  the  simulator  yields  the  expected  results  for  all  cases.  Unfortunately,  this  form  of 
simulation  leaves  the  designer  uncertain  that  all  circuit  design  errors  have  been  eliminated. 


‘This  research  was  supported  by  the  Defense  Advanced  Research  Projects  Agency,  ARPA  Order  Number 
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Stories  abound  of  errors  that  remain  undetected  despite  many  hours  of  simulation  and  even 
actual  circuit  operation.  Conventional  wisdom  holds  that  logic  simulators  are  incapable 
of  more  rigorous  verification.  They  are  viewed  in  the  same  class  as  program  debuggers — 
useful  tools  for  informal  testing,  but  nothing  more. 

Formal  verification  involves  proving  that,  under  some  abstract  model  of  system  operation, 
the  circuit  will  behave  as  specified  for  all  possible  input  sequences.  A  formal  proof  gives 
strong  confidence  that  the  circuit  will  function  correctly.  In  this  paper,  we  will  show  that 
a  logic  simulator  can  form  the  basis  of  a  formal  verifier.  At  first,  this  claim  might  seem 
both  obvious  and  of  little  practical  value,  since  most  systems  are  too  complex  to  simulate 
exhaustively.  We  will  argue  to  the  contrary  on  both  points.  When  the  circuit  has  potential 
for  sequential  behavior,  even  simulating  all  possible  input  patterns  may  fail  to  detect  an 
error.  Furthermore,  verification  by  simulation  can  be  made  practical  for  a  significant  class 
of  circuits. 

Formal  verification  does  not  guarantee  that  the  actual  circuit  will  operate  properly.  The 
assumptions  made  in  the  abstract  model  may  not  hold  in  the  physical  implementation. 
For  example,  most  methods  of  verifying  digital  systems  assume  that  the  circuit  adheres 
to  a  logic  abstraction  whereby  all  signals  can  be  represented  by  discrete  values.  Without 
such  an  abstraction,  verification  would  be  tedious,  if  not  impossible.  Design  errors  that 
cause  marginal,  nondigital  circuit  behavior  may  not  be  detected  by  verification  against 
such  a  model.  Similar  problems  arise  in  program  verification.  For  example,  most  proofs 
of  program  correctness  abstract  the  finite  arithmetic  implemented  by  computers  as  oper¬ 
ations  over  the  integer  or  real  domain.  A  verification  against  such  a  model  cannot  detect 
errors  due  to  arithmetic  overflow  or  underflow.  In  discussing  formal  verification,  we  must 
remember  that  the  level  of  confidence  it  provides  is  only  as  strong  as  the  degree  to  which 
the  abstract  model  matches  actual  system  operation. 

1.1  Structural  Approaches 

Most  hardware  verification  methodologies  [1,2,16,17,21,22,23,24]  utilize  structural  tech¬ 
niques.  In  such  an  approach,  the  circuit  is  described  hierarchically,  where  a  component 
is  defined  at  one  level  in  the  hierarchy  as  an  interconnection  of  components  defined  at 
lower  levels.  The  system  specification  consists  of  a  description  of  the  behavior  of  every 
component  at  each  level  of  the  hierarchy.  Verification  then  involves  proving  that  each  com¬ 
ponent  implements  its  part  of  the  specification,  assuming  that  its  constituent  components 
implement  theirs. 

Structural  verifiers  have  several  noteworthy  strengths.  They  can  exploit  the  circuit  hier¬ 
archy  to  reduce  proof  complexity,  since  a  proof  is  required  only  for  each  unique  circuit 
component.  Many  large,  but  highly  structured  circuits  have  been  verified  structurally. 
Second,  they  can  naturally  be  extended  to  parameterized  circuit  descriptions,  proving  the 


correctness  of  entire  families  of  circuits  [9j.  Finally,  structural  verifiers  can  apply  different 
modeling  abstractions  according  to  the  level  in  the  hierarchy,  such  as  representing  signals 
at  lower  levels  as  bits  and  at  higher  levels  as  integers  [2]. 

On  the  other  hand,  these  verifiers  have  several  shortcomings.  Even  when  automated,  they 
require  the  user  to  specify  the  intended  behavior  of  each  component  in  the  circuit  hierarchy. 
The  verifier  serves  largely  as  a  “proof  checker”,  making  sure  that  each  component  fulfills 
its  specification.  Many  circuits  are  not  designed  to  facilitate  component  specifications, 
and  hence  verification  requires  much  tedious  effort  on  the  part  of  the  user.  Consider,  for 
example,  an  adder  circuit  that  utilizes  carry-lookahead.  Although  the  addition  function 
is  straightforward  to  specify,  the  low  level  details  of  the  implementation  are  complex. 
Furthermore,  the  circuit  contains  many  different  component  types  and  hence  requires  a 
lengthy  specification  and  verification.  For  such  a  circuit,  a  verification  method  that  allows 
the  user  to  deal  with  the  overall  input-output  behavior  would  be  far  preferable. 

As  a  second  shortcoming,  most  structural  verifiers  use  highly  simplified  mode's  of  electri¬ 
cal  and  timing  behavior  to  make  the  proof  and  component  specifications  tractable.  Most 
assume,  for  instance,  that  the  circuit  components  operate  as  unidirectional  logic  elements 
computing  outputs  in  response  to  their  inputs.  In  actual  circuits  electrical  behavior  can 
be  far  more  subtle,  such  that  the  behavior  of  a  component  depends  on  its  operating  envi¬ 
ronment.  As  an  example,  the  direction  of  information  flow  through  a  CMOS  transmission 
gate  is  determined  solely  by  the  driving  capabilities  of  the  circuitry  at  either  end  [10]. 
Clearly,  any  specification  of  such  a  gate  must  include  restrictions  on  the  environment  in 
which  it  is  placed.  As  a  notable  exception  to  these  highly  simplified  models,  Weise  [23,24] 
has  developed  a  verifier  that  proves  the  correctness  of  MOS  circuits  under  a  model  that 
includes  detailed  electrical  and  timing  information.  His  verifier  automatically  checks  every 
environment  in  which  components  are  placed  for  compliance  with  the  preconditions  for 
correct  operation.  In  general,  however,  prospects  do  not  look  good  for  automating  struc¬ 
tural  verifiers  to  the  point  where  circuits  can  be  verified  with  little  manual  effort  and  with 
realistic  circuit  models.  Formulating  the  proper  set  of  assertions  about  each  component 
requires  a  more  sophisticated  reasoning  capability  than  will  be  automated  in  the  near 
future. 

1.2  A  Behavioral  Approach 

This  paper  proposes  a  behavioral  approach  to  circuit  verification.  In  this  approach,  the 
verifier  applies  logic  simulation  to  compute  the  circuit  response  to  a  series  of  stimuli  chosen 
to  detect  all  possible  design  errors.  The  user  is  freed  from  the  tedium  of  proving  the 
correctness  of  every  component.  Instead,  the  circuit  is  viewed  at  a  higher  level  in  terms  of 
its  desired  input-output  or  state  transition  behavior.  More  realistic  circuit  models  can  be 
used,  because  only  the  simulator  need  be  concerned  with  the  modeling  defails. 


Although  this  approach  to  hardware  verification  overcomes  several  weaknesses  of  structural 
verifiers,  it  cannot  match  some  of  their  strengths.  Simulation  cannot  exploit  hierarchy  very 
effectively,  because  the  different  instances  of  a  component  can  have  different  stimuli  and 
hence  must  all  be  evaluated.  There  is  also  no  known  way  to  simulate  an  entire  class  of 
circuits  in  a  single  run.  Perhaps  the  ideal  verifier  would  combine  both  styles.  A  hybrid 
approach  would  use  behavioral  verification  to  prove  the  correctness  of  a  set  of  components 
forming  some  intermediate  level  in  the  circuit  hierarchy.  This  would  avoid  the  need  to 
specify  the  behavior  of  the  low  level  components  and  could  employ  the  detailed  circuit 
models  required  at  these  levels.  Structural  verification  would  then  be  applied  to  the 
hierarchical  composition  of  the  intermediate  components,  exploiting  the  regularity  of  their 
interconnections  and  their  higher  abstraction  levels.  Thus  the  work  presented  here  should 
be  viewed  as  complementing  structural  verification,  rather  than  seeking  to  replace  it. 


1.3  Overview  of  the  Methodology 

The  task  of  evaluating  a  circuit  by  simulating  its  response  to  a  set  of  stimuli  relates  closely 
to  the  “machine  identification”  problem  first  described  by  Moore  [18].  He  showed  that, 
in  general,  no  finite  set  of  stimuli  could  fully  characterize  the  behavior  of  a  sequential 
system.  He  suggested  overcoming  this  problem  by  fixing  an  upper  bound  on  the  total 
number  of  system  states.  Unfortunately,  for  circuits  of  significant  size,  this  bound  is  too 
high  for  Moore’s  identification  algorithm  to  be  practical.  Instead,  our  method  overcomes 
the  identification  problem  by  simulating  the  behavior  over  a  three- valued  domain  with  con¬ 
ventional  Boolean  values  0  and  1,  plus  a  value  X  representing  an  undefined  or  uninitialized 
signal.  Such  a  capability  is  found  in  most  logic  simulators  [12].  In  addition  to  supplying 
input  patterns  during  simulation,  we  assume  that  the  user  can  issue  ERASE  commands, 
causing  all  state  variables  to  be  set  to  X.  Although  the  power  of  three- valued  simulation 
has  been  studied  extensively  in  the  context  of  hazard  detection  [6,15,25],  its  potential  role 
in  circuit  verification  has  not  been  widely  recognized. 

In  the  interest  of  generality  and  simplicity,  the  paper  views  hardware  specification,  circuit 
behavior,  and  logic  simulation  in  a  rather  abstract  way.  The  desired  behavior  is  specified 
by  a  (Moore  model)  finite  state  automaton.  The  circuit  is  also  a  finite  state  automaton, 
with  a  particular  binary  coding  of  the  states.  Although  this  is  an  unconventional  view 
of  a  circuit,  we  will  argue  its  appropriateness  for  behavioral  verification,  where  the  focus 
is  on  how  the  circuit  operates  rather  than  how  it  is  constructed.  Circuit  verification 
involves  proving  that  the  specification  and  circuit  automata  have  equivalent  input-output 
behavior.  The  simulator  models  the  behavior  of  the  circuit  automaton,  computing  new 
state  and  output  values  in  response  to  inputs  supplied  by  the  user.  A  mild,  monotonicity 
property  is  imposed  on  the  simulation  of  three-valued  behavior  to  capture  the  notion  that 
X  represents  an  unknown  or  ambiguous  digital  value. 


The  style  of  simulation  required  to  prove  correctness  depends  on  the  nature  of  the  system 


specification.  A  definite  system  [14,19],  for  which  the  behavior  depends  on  only  a  bounded 
number  of  previous  inputs,  can  be  verified  by  straightforward  “black-box”  simulation. 
Black-box  simulation  involves  simply  observing  the  output  produced  by  the  simulated 
circuit  in  response  to  a  sequence  of  input  and  ERASE  commands  with  no  consideration 
of  the  internal  circuit  structure.  Verifying  the  implementation  of  an  indefinite  system, 
on  the  other  hand,  requires  a  more  implementation-specific  “state  transition”  simulation. 
With  this  method,  key  circuit  state  variables  are  identified,  and  the  different  possible  state 
transitions  simulated.  In  either  case,  the  verification  requires  little,  if  any,  understanding 
of  the  detailed  circuit  design. 

Circuit  verifiers  can  err  in  two  different  ways.  One  that  rejects  a  correct  circuit  gives  a 
false  negative  response,  whereas  one  that  accepts  an  incorrect  circuit  gives  a  false  positive 
response.  This  paper  is  concerned  mainly  with  avoiding  false  positive  responses.  Such  a 
response  has  more  potential  for  danger — it  may  cause  a  defective  design  to  be  implemented 
or  put  into  service.  Furthermore,  deciding  whether  a  simulator  has  produced  a  false 
negative  response  requires  more  detailed  information  about  the  circuit  electronics  and  the 
simulation  algorithm  than  can  be  presented  in  a  general  way.  However,  for  the  simulation 
sequences  presented  in  this  paper,  a  false  negative  response  must  have  a  particular  form, 
namely  the  simulator  will  produce  X  on  some  output  when  0  or  1  was  expected. 

As  mentioned  earlier,  any  approach  to  formal  verification  guarantees  proper  circuit  opera¬ 
tion  only  if  the  assumptions  made  in  the  abstract  model  hold  in  the  circuit  implementation. 
For  the  case  of  simulation-based  verification,  we  must  assume  that  the  actual  circuit  be¬ 
haves  identically  to  its  simulation.  When  a  circuit  has  been  “verified”  by  simulation,  it 
simply  means  that  it  has  no  errors  that  could  be  detected  by  simulating  additional  pat¬ 
terns.  It  is  important  to  maintain  this  perspective  on  the  problem  addressed  by  this  paper. 
It  reflects  a  weakness  intrinsic  to  any  approach  to  verification  and  not  to  simulation  alone. 

1.4  Contents  of  Paper 

This  paper  presents  both  theoretical  and  practical  aspects  of  a  hardware  verification 
methodology  based  on  multi-valued  logic  simulation.  Section  2  illustrates  the  key  ideas  by 
means  of  several  circuit  examples.  Section  3  gives  a  notation  and  mathematical  background 
for  describing  system  specifications,  digital  circuits,  logic  simulators,  and  the  verification 
problem.  Section  4  gives  a  formal  characterization  of  the  capabilities  and  limitations  of 
black-box  simulation.  Section  5  shows  how  these  limitations  are  overcome  by  state  tran¬ 
sition  simulation. 

Section  6  discusses  methods  to  improve  the  computational  efficiency  of  the  verifier.  Two 
methods  are  proposed  to  reduce  the  computational  effort  in  verifying  large  digital  systems: 
input  weakening  and  symbolic  simulation.  Input  weakening  involves  using  the  value  X  on 
an  input  to  represent  “don’t  care”,  thereby  reducing  the  total  number  of  patterns  that  need 


to  be  simulated.  Symbolic  simulation  involves  augmenting  a  simulator  with  a  symbolic 
Boolean  manipulator  to  compute  the  behavior  of  the  circuit  over  input  patterns  containing 
Boolean  variables.  Section  7  demonstrates  a  practical  application  of  the  methodology  to 
the  verification  of  a  random-access  memory.  By  exploiting  input  weakening,  an  n-bit 
memory  can  be  fully  verified  by  simulating  0{n  log  n)  patterns,  even  though  the  circuit 
has  2"  possible  states.  Section  8  concludes  the  paper  with  a  discussion  of  the  method. 

All  circuit  examples  shown  in  this  paper  are  designed  in  MOS  technology.  This  choice 
reflects  the  historical  background  of  the  research  as  well  as  the  belief  that  MOS  circuits 
form  a  particularly  difficult  class  for  hardware  verification.  In  particular,  state  can  be 
stored  as  dynamic  charge  on  capacitive  nodes.  Unlike  circuits  where  all  state  is  stored 
in  feedback  loops,  there  is  no  straightforward  way  to  identify  all  state  variables.  In  fact, 
design  errors  commonly  introduce  unintended  state  variables  and  sequential  dependencies. 
The  methodology  presented  here,  however,  applies  to  most  digital  technologies,  with  the 
caveat  that  circuits  are  assumed  to  operate  on  synchronized  input  data.  Asynchronous 
systems  seems  to  call  for  more  powerful  class  of  verification  tools,  such  as  the  model  checker 
of  Clarke,  et  al  [3,7],  since  they  cannot  be  viewed  simply  as  processing  a  single  sequence 
of  input  data. 

This  research  provides  two  major  contributions  to  the  state  of  the  art  in  circuit  validation. 
First,  it  presents  a  simple,  yet  powerful,  method  of  proving  the  correctness  of  digital 
hardware.  Second,  it  provides  insights  into  ways  to  better  utilize  a  simulator  even  when 
only  informal  validation  is  sought.  It  shows  that  by  exploiting  a  latent  capability  found 
in  most  logic  simulators,  namely  three-valued  modeling,  more  rigorous  validation  can  be 
obtained  at  comparable  cost. 

2  Verification  Examples 

Before  proceeding  with  the  mathematical  formalism,  we  present  the  main  concepts  via 
several  circuit  examples.  These  examples  illustrate  several  pitfalls  of  simulation  and  how 
three-valued  modeling  can  be  exploited  to  overcome  them. 

2.1  Definite  Systems 

Consider  the  seemingly  simple  task  of  proving  that  a  circuit  implements  a  NOR  logic  gate. 
Figure  1  shows  two  proposed  implementations  in  CMOS  technology  [10].  If  we  were  to 
simulate  these  circuits  using  a  simulator  that  can  model  a  MOS  circuit  at  the  transistor 
level[4],  the  following  responses  would  be  produced  when  the  input  patterns  are  applied 
in  the  sequence  shown: 


Incorrect 


Correct 


B 


A 

OUTi 


A 

out2 


Figure  1:  Implementations  of  a  NOR  Gate  in  CMOS 
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The  two  circuits  appear  identical  for  all  possible  input  combinations,  as  they  would  be  in 
actual  implementations  of  the  circuits.  However,  only  the  second  circuit  is  a  valid  NOR 
gate.  The  first  is  a  two-state  sequential  circuit,  because  when  A  =  1  and  B  =  0,  the 
output  node  is  electrically  isolated  from  all  others  and  remains  charged  at  its  previous 
value.  Due  to  the  order  in  which  the  input  combinations  were  applied,  it  just  happened 
that  the  previous  value  of  OUTi  equaled  the  value  a  NOR  gate  should  produce  for  this  input 
combination.  On  the  other  hand,  had  this  input  combination  been  simulated  immediately 
after  the  combination  A  =  B  =  0,  the  output  would  have  been  1. 

This  example  illustrates  a  common  problem  in  testing  a  circuit  by  simulation  even  when 
rigorous  verification  is  not  sought.  A  design  error  introduces  an  unintended  sequential 
dependency  in  the  circuit,  but  this  error  remains  undetected  because  of  the  particular 
order  in  which  the  test  sequences  are  simulated.  Clearly,  such  a  condition  is  not  acceptable 
for  formal  verification. 

Suppose,  on  the  other  hand,  that  an  ERASE  command  is  given  before  simulating  each 
input  combination,  causing  all  state  variables  to  be  set  to  X.  Such  a  simulation  would 
produce  the  following  results: 
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The  presence  of  an  X  on  OUTj  indicates  that  the  output  of  this  circuit  may  not  be  uniquely 
defined  when  A  =  1  and  B  =  0  (or  it  could  be  a  false  negative  response  by  a  valid  circuit). 
On  the  other  hand,  each  input  combination  produces  a  unique  response  for  the  second 
circuit,  and  since  the  responses  match  those  of  a  NOR  gate,  one  can  conclude  the  circuit  is 
correct.  This  conclusion  can  be  drawn  without  any  further  information  about  the  structure 
of  the  circuit  or  the  number  of  state  variables. 

A  combinational  system  such  as  a  NOR  gate  is  1 -definite;  its  output  at  any  time  depends 
only  on  the  most  recent  input.  The  method  shown  above  generalizes  to  any  definite  system 
specification,  where  the  output  depends  only  on  the  most  recent  k  inputs  for  some  constant 
k.  That  is,  suppose  for  every  possible  input  sequence  of  length  k,  setting  all  state  variables 
to  X  and  then  simulating  the  sequence  yields  an  output  equal  to  the  desired  value.  One 
can  then  safely  conclude  the  circuit  implements  the  specification. 

Observe  that  this  requirement  for  definiteness  applies  only  to  the  system  specification 
and  not  to  the  circuit  being  evaluated.  For  example,  the  simulator  is  able  to  detect  the 
incorrect  NOR  gate  even  though  the  circuit  itself  is  not  definite.  In  particular,  its  output 
depends  on  inputs  that  occurred  arbitrarily  long  ago  as  long  as  A  is  held  at  1  and  B  at  0. 


2.2  Indefinite  Systems 

Many  sequential  systems  are  not  definite.  For  example,  a  simple  1-bit  latch  has  an  output 
dependent  on  an  input  that  occurred  arbitrarily  long  in  the  past  as  long  as  no  new  value 
is  written  into  it  (by  setting  its  LOAD  input  to  1).  For  such  a  system,  given  any  value 
k,  there  will  always  be  an  input  sequence  of  length  k  that  does  not  cause  the  system  to 
produce  a  unique  output.  When  simulating  this  sequence  following  an  ERASE  command, 
even  a  correctly  designed  circuit  will  give  an  X  on  the  output. 

In  Section  4  we  will  show  that  for  any  indefinite  system,  there  is  no  way  to  prove  that  a 
circuit  implements  its  specification  by  simply  observing  the  output  values  resulting  from 
a  sequence  of  input  patterns  and  ERASE  commands.  This  general  limitation  of  black-box 
simulation  can  be  illustrated  using  a  1-bit  latch  circuit.  Consider  a  simulation  sequence 
that  is  claimed  to  detect  any  defective  latch  design.  Since  the  sequence  is  finite,  there 
must  be  some  value  l  such  that  the  LOAD  input  is  never  held  at  0  for  /  or  more  consecutive 
patterns. 


Consider  the  circuit  of  Figure  2  consisting  of  a  correct  latch  with  additional  circuitry 
implementing  a  “booby  trap” .  Whenever  a  value  is  written  into  the  latch,  all  bits  in  the 
booby  trap  shift  register  are  cleared  to  0.  The  output  of  the  shift  register  is  EXCLUSIVE- 
OR’ed  with  the  latch  output  to  produce  the  circuit  output  OUT'.  Thus,  the  circuit  behaves 
as  a  proper  latch  as  long  as  the  shift  register  output  equals  0.  If  no  further  data  is  written, 
a  1  will  shift  through  the  register  until  it  ultimately  causes  the  circuit  output  OUT'  to 
be  complemented.  Clearly,  this  circuit  does  not  behave  as  a  latch  should.  However,  the 
proposed  sequence  does  not  cause  enough  consecutive  shift  operations  for  the  defective 
circuit  to  behave  differently  from  the  correct  one. 

Less  obviously,  even  attempts  to  expose  the  booby  trap  by  giving  ERASE  commands  or 
by  giving  input  sequences  containing  ^’s  will  fail  to  distinguish  the  correct  latch  from 
the  circuit  of  Figure  2.  Unlike  the  NOR  gate  example,  any  action  that  would  cause  the 
simulator  to  produce  output  X  for  the  incorrect  circuit  would  also  cause  it  to  produce 
output  X  for  the  good  circuit.  Thus,  the  proposed  simulation  sequence  cannot  distinguish 
between  a  correct  circuit  and  this  incorrect  one.  This  argument  holds  for  any  simulation 
sequence  by  making  l  sufficiently  large. 

To  verify  indefinite  systems,  more  information  is  required  about  the  circuit  state  variables 
and  their  relation  to  the  states  of  the  system  specification.  However,  in  the  spirit  of  black¬ 
box  simulation,  we  would  like  to  minimize  the  amount  of  detail  about  the  circuit  structure 
that  the  user  must  provide.  To  achieve  this  goal,  assertions  about  the  state  variables 
and  how  they  are  transformed  by  the  input  values  are  expressed  in  a  notation  similar  to 
the  Floyd-Hoare  assertion  method  of  program  verification  [8,11].  Each  assertion  is  then 
verified  by  a  short  simulation  sequence. 


Figure  3:  Latch  Circuit 


A  circuit  assertion ,  denoted  by  an  equation  of  the  form  P  {  I  }  N  A  O,  consists  of  4 
predicates  over  the  circuit  input,  output,  and  state  variables.  Predicate  P  specifies  a 
precondition  on  the  state  variables,  I  an  action  on  the  input  variables,  N  a  postcondition 
on  the  state  variables,  and  O  a  postcondition  on  the  output  variables.  Each  predicate  is 
the  logical  conjunction  of  terms  of  the  form  v  =  1  or  u  =  0,  where  v  is  circuit  variable.  A 
circuit  assertion  can  be  interpreted  as  a  statement  that  for  any  circuit  state  satisfying  P 
and  for  any  action  satisfying  /,  the  new  circuit  state  will  satisfy  N,  and  the  output  will 
satisfy  O. 

As  an  example,  consider  an  implementation  of  the  1-bit  latch  illustrated  in  Figure  3. 
No  internal  details  of  the  circuit  are  shown  except  that  the  bit  is  stored  in  a  feedback 
path  containing  two  electrical  nodes  Q  and  fj-  The  following  assertions  specify  the  state 
transition  behavior  of  the  circuit  where  a  ranges  over  0  and  1: 

true  |  DATA  =  a  A  LOAD  =  l}Q  =  aA^=-’aA  OUT  =  a 

Q  =  a  A  LOAD  =  0  }  Q  =  a  A  §  =  -^a  A  OUT  =  a 

The  first  equation  asserts  that  a  write  operation  sets  the  state  of  a  latch,  while  the  second 
asserts  that  the  latch  state  does  not  change  as  long  as  no  new  data  is  written.  In  both 
cases  the  value  of  OUT  should  equal  that  of  Q. 

Given  an  assertion  P  {  I  }  N  AO,  its  verification  by  simulation  involves  the  following  steps. 
An  ERASE  command  is  given  to  set  all  state  variables  to  X.  For  each  term  v  =  a  in  P 
(respectively  /),  state  variable  v  (resp.  input  variable  v)  is  set  to  a.  All  input  variables  not 
occurring  in  I  are  set  to  X.  The  simulator  then  computes  the  resulting  output  and  new 
state.  For  each  term  v  =  a  in  N  (respectively  O),  state  variable  v  (resp.  output  variable 
v)  is  tested  for  equality  with  a.  If  all  of  these  tests  hold,  then  the  assertion  is  proved. 

For  example,  consider  the  latch  circuit  of  Figure  3,  and  the  faulty  circuit  formed  by  adding 
the  booby  trap  of  Figure  2  to  it.  Simulating  the  four  sequences  specified  by  the  assertions 


would  yield  the  following  results: 
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The  defective  circuit  passes  the  first  two  tests  when  new  data  is  written,  because  this 
causes  the  shift  register  to  be  cleared.  For  the  final  two  tests,  however,  all  state  variables 
with  the  exception  of  Q  and  Q  are  initialized  to  X.  The  shift  register  output  will  remain 
at  X,  causing  an  X  to  appear  on  OUT'  and  the  tests  to  fail. 


3  Mathematical  Formulation 


The  examples  of  the  previous  section  illustrate  the  main  ideas  of  our  verification  method¬ 
ology.  We  will  now  proceed  with  a  more  formal  presentation,  showing  that  these  ideas 
apply  to  general  classes  of  circuits.  This  section  develops  a  mathematical  abstraction  of 
logic  circuits,  simulators,  and  the  verification  problem. 

3.1  Notation 

We  adopt  a  notation  that  represents  the  system  input,  output,  and  state  values  as  vectors. 
The  history  of  inputs  applied  to  a  system  is  denoted  by  a  sequence  of  vectors. 


p:  the  number  of  system  inputs. 

B:  {0,  l},  the  Boolean  domain. 

Bn:  {(xi, . . .  ,xn)|x,  £  B},  Boolean  vectors  of  size  n. 

:  all  length  l  sequences  with  elements  in  Bp. 

Uo<i<oo  all  finite  sequences  with  elements  in  Bp. 

T:  {0, 1,X},  the  ternary  domain,  partially  ordered  X  <  1  and  X  <  0. 

Tn:  {(ii, . . .  ,xn)|x,  €  T},  ternary  vectors  of  size  n,  partially  ordered  x  <  y  if 
x*  <  y i  for  all  1  <  *  <  n. 


'Iq:  all  length  l  sequences  with  elements  in  Tp. 

'F:  Uo<i<oo  all  finite  sequences  with  elements  in  Tp,  partially  ordered 
[ai, . . . ,  a4]  <  [bi, . . . ,  6(]  if  s  <  t  and  2,-*  <  bt~,  for  all  0  <  i  <  s. 

e:  the  empty  sequence. 

a  ■  0 :  the  concatenation  of  sequences  a  and  (3. 


3.2  Information  Ordering 

The  partial  ordering  X  <  0  and  X  <  1  orders  values  by  their  “information  content.”  That 
is,  X  indicates  an  absence  of  information  while  0  and  1  represent  specific,  fully-defined 
values.  When  speaking  of  domains  ordered  by  information  content  values  a  and  b  are 
said  to  be  “consistent”  if  either  a  <  b  or  b  <  a,  and  “inconsistent”  otherwise.  Value  a  is 
“weaker”  than  b  if  a  <  b,  i.e.,  a  <  b  and  a  ^  b. 

The  information  ordering  is  extended  to  vectors  and  vector  sequences  by  adopting  the 
convention  that  one  value  is  less  than  another  if  the  elements  of  the  first  are  consistent 
with  those  of  the  second,  but  the  first  contains  less  information.  More  precisely,  for  vectors 
in  Tn,  one  vector  is  less  than  or  equal  to  another  if  each  element  of  the  first  is  less  than  or 
equal  to  each  element  of  the  second.  For  sequences  a,  (3  E  'F,  a  is  less  than  or  equal  to  (3 
if  the  elements  of  a  are  less  than  or  equal  to  the  corresponding  final  elements  of  (3.  That 
is,  the  history  given  by  a  is  consistent  with  the  most  recent  history  given  by  0,  but  may 
contain  less  information.  The  motive  for  this  convention  on  the  ordering  of  different  length 
sequences  will  become  clear  when  we  study  the  monotonicity  properties  of  the  simulator. 
As  a  special  case,  sequences  of  Boolean  vectors,  aj  £  $,  are  ordered  a  <  0  when  a  is  a 
suffix  of  0. 

Definition  1  For  partially  ordered,  sets  D\,  Di  a  monotonic  function  g\D\  — *•  D2  satisfies 


a  <  b 


g(a)  <  g(b) 


for  all  a,b  6  D j.  Similarly,  a  monotonic  function  with  multiple  arguments  satisfies  this 
property  for  each  argument. 

For  any  program  that  processes  data  ordered  by  information  content,  such  as  a  logic 
simulator,  monotonicity  expresses  an  important  property.  Suppose  the  program  is  given 
a  stimulus  containing  incomplete  information,  e.g.,  having  some  inputs  equal  to  X.  If 
the  program  obeys  monotonicity,  it  will  produce  a  response  consistent  with  but  possibly 
weaker  than  the  response  it  would  produce  given  a  stronger  stimulus. 


Definition  2  For  partially  ordered  sets  D i  and  D2  with  subsets  D[  and  D'2,  respectively, 
a  monotonic  extension  of  function  f  :D[  — ►  D2  is  a  function  g\  D\  — ►  D2  such  that  g  is 
monotonic  and  f{a)  =  g(a)  for  all  a  €  D[.  Similarly,  a  monotonic  extension  of  a  multiple 
argument  function  must  satisfy  these  properties  for  each  argument. 


As  an  example,  the  OR  function  can  be  extended  monotonically  from  the  Boolean  to  the 
ternary  domain  in  several  different  ways,  including  the  following: 


a  V  b  =  < 


1, 

0, 

X, 


a  —  1  or  b  =  1 
a  =  0  and  6  =  0 
else. 


(1) 


Other  extensions  yield  X  when  a  =  1  and  6  =  X  or  vice-versa.  These  more  pessimistic 
extensions  are  still  monotonic  but  would  tend  to  cause  false  negative  results. 


3.3  System  Specification 

The  system  to  be  implemented  has  p  inputs  and  m  outputs,  each  of  which  may  equal  0  or 
1.  Hence  the  system  may  be  described  as  a  finite  automaton  with  input  alphabet  Bp  and 
output  alphabet  Bm. 

Definition  3  A  system  specification  At  is  a  triple  (Q,  Next,  Out)  with 
Q:  a  finite  set  of  states, 

Next:  the  next  state  function  Next :  Q  x  Bp  — ►  Q,  and 
Out:  the  output  function  Out :  Q  — ►  Bm. 

Function  Next  must  be  a  surjection,  that  is,  for  every  q  €  Q,  there  must  be  a  q'  G  Q  and 
a  G  Bp  such  that  q  =  Next(q' ,a). 

A  system  with  a  surjective  next  state  function  cannot  have  any  unreachable  states.  This 
restriction  is  imposed  for  technical  reasons  but  should  not  limit  the  class  of  actual  systems 
under  consideration,  because  there  would  be  no  reliable  way  to  put  the  system  in  a  state 
that  cannot  be  reached  by  any  sequence  of  state  transitions.  This  restriction  is  much 
milder  than  the  strong  connectivity  property  assumed  by  Moore  [l8j. 

The  function  Next  is  extended  to  input  sequences  to  yield  the  state  after  all  inputs  have 
been  applied,  i.e.,  to  a  function  Next:Q  x  $  — ►  Q  defined  recursively  as 

Next(q,e)  =  q 


Next{q,a-x)  =  Next(Next(q,a),x). 


Proposition  1  For  any  k  >  0,  The  extended  function  Next:Q  x  <f>fc  — ♦  Q  is  a  surjection. 

Proof:  By  induction  on  k  and  the  surjectivity  of  Next  when  applied  to  single  inputs. 

□ 

The  function  FinalOut:  Q  x  $  — >  Bm  is  defined  to  yield  the  final  output  after  a  sequence 
of  inputs  has  been  applied,  i.e., 

FinalOut{q,a)  —  Out(Next(q,  a)). 

Proposition  2 

Next(q ,  a  ■  /?)  =  Next(Next(q,  a),  ft) 

and 

FinalOut{q,  a  •  0)  =  FinalOut(Nezt(q,  a) , /3) 

Proof:  By  induction  on  the  length  of  0. 

□ 

3.4  Circuit  Model 

A  circuit  is  also  a  finite  automaton  but  with  states  encoded  by  s  Boolean  variables. 
Definition  4  A  circuit  C  is  a  triple  (s,  next,  out)  with 

s:  the  number  of  state  variables, 
next:  the  next  state  function  next:  B*  x  Bp  —*  Bs,  and 
out:  the  output  function  out:  B’  — >  Bm. 

This  definition  of  a  circuit  differs  significantly  from  that  assumed  by  other  verifiers. 
Whereas  structural  verifiers  describe  a  circuit  as  a  set  of  interconnected  elements,  our 
abstraction  ignores  the  physical  structure  altogether.  Instead,  it  views  a  circuit  at  the 
level  seen  by  the  user  of  a  logic  simulator.  That  is,  the  program,  rather  than  the  user,  is 
responsible  for  determining  the  behavior  of  the  circuit  given  its  structure.  This  level  of 
detail  sulfices  for  the  paper,  because  our  goal  in  verification  is  only  to  ensure  that  the  user 
uncovers  any  design  errors  that  can  be  detected  by  the  simulator. 


Definition  5  Circuit  C  implements  specification  .M  when  there  exists  a  relation  £  C 
Q  x  B3  (for  “encodes”)  satisfying: 

1.  For  every  q  £  Q  there  exists  a  z  £  B3  for  which  q  £  z. 

2.  For  any  q  £  Q  and  z  £  B‘ 

q  £  z  =>  Out(q)  =  out(z), 

S.  For  any  q  £  Q,  z  £  B3,  and  x  £  Bp, 

q  £  z  =>  Next(q,x )  £  next(z,x). 


By  this  definition,  the  circuit  automaton  must  “cover”  the  input-output  behavior  of  the 
specification.  That  is,  for  any  initial  state  of  the  specification,  there  must  be  an  initial 
circuit  state,  such  that  the  two  automata  would  yield  identical  outputs  for  any  subse¬ 
quent  input  sequence.  However,  there  may  be  circuit  states  that  do  not  correspond  to 
any  specification  states,  such  as  those  involving  invalid  combinations  of  state  variables. 
Furthermore,  neither  automata  need  be  reduced — several  circuit  states  may  correspond  to 
a  single  specification  state  and  vice-versa. 


3.5  Simulator 


For  a  circuit  C  =  (s, next, out),  the  simulator  maintains  state  variables  z  £  T* ,  and  com¬ 
putes  the  behavior  according  to  functions  next:T *  x  Tp  —>  T3  and  out:T 3  — ►  Tm,  which 
are  arbitrary  monotonic  extensions  of  the  corresponding  circuit  functions.  The  simula¬ 
tor  implements  five  commands,  although  for  black-box  simulation  only  the  first  three  are 
allowed. 


Erase 
Cycle(i) 
Output 
SET(i,  b) 


causes  the  simulator  to  set  z ,  to  X  for  1  <  t  <  s. 
causes  the  simulator  to  set  z  to  next(z,  x). 
causes  the  simulator  to  print  out(z). 
causes  the  simulator  to  set  z,  to  b  for  6  £  T. 


OBSERVE(t):  causes  the  simulator  to  print  z,. 


3.6  Simulation  Experiment 


Definition  6  .4  simulation  experiment  consists  of  a  sequence  of  simulation  commands 
beginning  with  ERASE,  as  well  as  a  procedure  by  which  the  user  decides  whether  the  outcome 
is  acceptable.  The  decision  procedure  can  depend  only  on  the  values  produced  by  OUTPUT 
and  OBSERVE  commands. 

Definition  7  An  experiment  is  effective  for  specification  >1  when  the  simulation  of  a 
circuit  C  can  be  judged  acceptable  only  if  C  implements  At. 

This  condition  requires  that  the  verification  method  cannot  produce  any  false  positive 
responses. 

Definition  8  An  experiment  is  nontrivial  when  the  simulator  produces  an  acceptable  out¬ 
come  for  some  circuit  {s,  next,  out)  and  monotontc  extensions  of  next  and  out. 

This  condition  is  imposed  to  eliminate  the  otherwise  effective  test  of  rejecting  all  circuits. 


4  Black-Box  Simulation 


With  black-box  simulation,  the  user  is  limited  to  the  simulation  commands  ERASE,  CY¬ 
CLE,  and  OUTPUT.  No  direct  observation  or  modification  of  the  simulator  state  z  is 
permitted.  This  section  identifies  the  class  of  systems  that  can  be  verified  by  black-box 
simulation. 

Define  the  function  SimState :  'if  — ♦  T*  as  the  state  of  the  simulator  after  giving  an  ERASE 
command  followed  by  a  series  of  CYCLE  commands.  More  precisely 

SimState(e)  =  Xs 

SimState(a  ■  x)  =  next(SimState(a) ,  x ) 
where  X *  denotes  a  vector  of  size  s  with  each  element  equal  to  X. 

Similarly,  define  the  function  SimOut :  #  — ►  Tm  as  the  result  that  would  be  printed  by  an 
OUTPUT  command  following  the  simulation  of  some  input  sequence,  i.e., 

SimOut(a)  =  out(S  imS  tate(a)) . 


A  black-box  simulation  experiment  can  be  viewed  as  a  decision  procedure  that  either 
accepts  or  rejects  a  circuit  based  on  the  values  of  SimOut(a)  for  any  finite  number  of 
sequences  a  £  if. 


4.1  Definite  Systems 

Definition  9  For  any  k>0,  specification  X  is  k-definite  if 

FinalOut(qi,a)  =  FinalOut(q2,a ) 
for  any  a  E  and  any  q\,q2  £  Q, 

Definition  10  A  specification  is  definite  if  it  is  k-definite  for  any  k.  Otherwise  it  is 
indefinite. 

This  class  of  sequential  systems  was  first  identified  by  Kleene  [13].  Since  that  time,  various 
definitions  have  appeared,  viewing  sequential  systems  either  as  recognizers  [  19]  or  trans¬ 
ducers  [14].  Our  definition  most  closely  matches  that  of  Kohavi  [14].  However,  he  defines 
a  A: -definite  system  as  one  for  which  any  input  sequence  of  length  k  places  the  system  in 
a  unique  state,  whereas  we  only  require  the  sequence  to  cause  a  unique  output.  If  the 
specification  automaton  is  in  reduced  form,  the  two  definitions  are  equivalent. 

Proposition  3  A  k-definite  specification  is  also  l-definitc  for  any  l  >  k. 

Proof:  Any  sequence  in  is  of  the  form  0  ■  a  where  0  6  and  a  6  $jt.  For  any  states 
<711*72  G  Q i  let  q[  =  Next{qx,0)  and  q'2  =  Next(q2, 0).  By  Proposition  2  and  the  fact  that 
the  specification  is  A: -definite: 

FinalOut(qi,  0  •  a)  =  FinalOut(q[,  a)  =  FinalOut{q'2,  a)  =  FinalOut(q2, 0  •  a) 

□ 

4.2  Monotonicity  Properties 

In  this  section  we  will  prove  several  properties  of  the  logic  simulator  that  follow  from  the 
monotonicity  of  the  simulator  functions  next  and  out.  As  shall  be  seen,  monotonicity  pro¬ 
vides  the  primary  mechanism  by  which  one  can  guarantee  properties  of  a  circuit  knowing 
only  its  response  during  simulation. 

Lemma  1  The  functions  SimState  and  SimOut  are  monotonic. 

Proof:  We  will  prove  by  induction  on  the  length  of  a  that  for  any  a,  0  £  for  which 
a  <  /?,  we  have  SimState(a)  <  SimState(0).  First,  if  a  =  c,  then  S»'mState(a)  =  X ’ 


and  this  vector  is  less  than  or  equal  to  any  other  state  vector.  Otherwise,  if  a  has  nonzero 
length  and  a  <  3,  then  a  must  be  of  the  form  a'  ■  a  and  (3  must  be  of  the  form  3'  ■  6  where 
q'  <  3'  and  a  <  b.  Assuming,  by  induction,  that  SimState{a')  <  SimState{3')  and  given 
that  next  is  monotonic,  we  get 

SimState(a)  =  next(SimState(a'),a)  <  next[SimState(3'),b)  =  SimState(P). 

The  monotonicity  of  SimOut  follows  from  the  fact  that  both  out  and  SimState  are  mono¬ 
tonic,  because  a  composition  of  monotonic  functions  is  also  monotonic. 

□ 

The  monotonicity  of  SimState  and  SimOut  show  how  the  ERASE  command  and  the  three¬ 
valued  modeling  enhances  the  power  of  the  simulator.  If  an  ERASE  command  followed  by 
a  sequence  of  CYCLE  commands  causes  the  simulator  to  produce  a  0  or  1  on  some  output 
or  state  variable,  then  this  sequence  of  inputs  must  also  cause  the  circuit  to  produce  the 
same  output  or  state  regardless  of  the  initial  state.  As  a  special  case  of  this  lemma,  if 
sequence  a'  is  a  suffix  of  a,  then  SimOut(a')  <  SimOut(a),  i.e.,  the  simulation  of  the 
shorter  sequence  yields  an  output  consistent  with,  but  possibly  weaker  than,  the  output 
produced  for  the  longer  one. 

Lemma  2  For  any  k  >  0,  if  SimOut(a)  =  FinalOut(q,  a)  for  all  a  €  $jt  and  all  q  6  Q, 
then  the  simulated  circuit  C  implements  specification  At. 


Proof:  For  any  let 

and 


Qa  =  {Next{q',a)\q'  £  Q} 


Za  =  {z  £  B'\SimState(a.)  <  z} 

That  is  Qa  denotes  the  set  of  possible  states  for  the  specification  automaton  following 
input  sequence  a,  while  Za  denotes  the  set  of  possible  circuit  states  consistent  with  the 
state  of  the  simulator  after  simulating  the  sequence  a  following  an  ERASE  command.  By 
the  monotonicity  of  out ,  we  must  have  that  for  z  £  Za 


SimOut(a)  =  out(SimState(a ))  <  out{z). 


For  those  sequences  a  that  occur  in  the  condition  of  the  lemma,  SimOut(a)  is  maximal, 
i.e.,  SimOut(a)  £  Bm,  in  which  case  we  can  conclude  that  out(z)  =  SimOut(a)  for  all 
2  £  Za. 


Define  S  as 


£  =  U  Za). 

a6$* 


We  must  show  that  £  satisfies  the  three  properties  of  Definition  5. 
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First,  given  that  Next  is  surjective  for  input  sequences  of  length  k  (Proposition  1),  every 
state  q  must  be  in  set  Qa  for  some  a  E  $*..  The  set  Za  cannot  be  empty,  and  hence  q  £  z 
for  some  z. 

Second,  if  q  £  z ,  we  must  have  q  =  Next(q',a )  and  SimState(a)  <  z  for  some  q1  E  Q  and 
some  a  E  From  the  condition  of  the  lemma  it  follows  that 

Out{q)  =  FinalOut(q' ,  a)  —  SimOut(a)  =  out(z). 


Finally,  suppose  q  £  z,  i.e.,  for  some  a  =  [al7 . . . ,  ak\  we  have  q  E  Qa  and  SimState(a)  <  z. 
Consider  any  x  E  Bp ,  and  let  7  =  [au  . . . ,  ak,  x\  and  0  =  [a2, . . . ,  ak,  x\.  By  definition, 
Next(q,x )  E  Qg.  Since  0  <  7  [0  is  a  suffix  of  7),  and  both  SimState  and  next  are 
monotonic 


SimState{0)  <  SimState(^)  =  next(SimState(a) ,  x)  <  next(z,x ) 

Therefore  next(z,x)  E  Zg  by  the  definition  of  Zg  and  hence  Next{q,x)  £  next(z,  x) . 

□ 

This  lemma  provides  the  key  to  proving  that  a  simulator  can  verify  that  a  circuit  imple¬ 
ments  a  A:-definite  specification  by  simulating  it  for  all  input  sequences  of  length  k. 


Lemma  3  If  circuit  C  implements  specification  M  then  for  all  a  E  ^  and  all  0  E  $  such 
that  a  <  0: 

SimOut(a)  <  FinalOut(q,  0) 


for  all  q  E  Q. 


Proof:  We  will  prove  by  induction  on  the  length  of  0  that  for  some  z  E  B“  such  that 
Next{q,0 )  £  z,  we  have  SimState{0 )  <  z.  Given  this,  we  can  infer  by  the  monotonicity 
of  SimOut  and  out,  and  by  condition  2  of  Definition  5  that 

SimOut{a)  <  SimOut{0)  =  out{SimState{0))  <  out(z)  =  FinalOut{q,  0). 

To  prove  the  induction  hypothesis,  for  0  =  t,  we  have  that  SimState(0)  =  X'  and 
hence  the  hypothesis  holds  trivially.  Now  suppose  that  0  is  of  the  form  0  =  0'  ■  6,  that 
Next(q,0')  £  z',  and  SimState(0')  <  z'.  By  definition 

Next(q,0 )  =  Next(Next(q,0'),b) 

and  therefore  by  condition  3  of  Definition  5 


Next(q,0 )  £  next(z' ,b) . 


By  the  monotonicity  of  next 


SimState(p)  =  next(SimState(p'),b )  <  next(z',b ) 

Hence,  if  we  let  z  —  next(z',b)  the  induction  hypothesis  will  hold. 

□ 

This  lemma  implies  that  if  the  specification  has  states  <71  and  q2  for  which  FinalOut(qi,  a)  7= 
FinalOut{qi,  a),  for  some  sequence  a,  then  some  element  of  SimOut(a)  must  equal  X 
even  for  a  correctly  designed  circuit.  This  property  is  used  in  designing  a  booby  trap  for 
an  indefinite  system. 


4.3  Expressive  Power 

VVe  are  now  ready  to  prove  a  main  result  of  this  paper,  characterizing  the  capabilities  and 
limitations  of  black-box  simulation. 


Theorem  1  There  exists  an  effective,  nontrivial,  black-box  simulation  experiment  for  spec¬ 
ification  M  if  and  only  if  M  is  definite. 


Proof:  First,  suppose  M  is  A:-definite  for  some  value  k.  Consider  the  simulation  experiment 
consisting  of  executing  the  sequence  of  commands  required  to  compute  SimOut(a)  for  each 
a  6  and  accepting  the  circuit  if  SimOut(a)  =  FinalOut(q,  a)  for  all  a  and  any  choice 
°f  9  G  Q  (in  a  A: -definite  specification,  the  choice  of  initial  state  makes  no  difference.) 
Lemma  2  shows  that  this  experiment  is  effective. 


Furthermore,  the  circuit  illustrated  in  Figure  4,  consisting  of  a  p-bit  wide,  A:-bit  long  shift 
register  to  store  the  most  recent  k  inputs  plus  logic  to  compute  the  circuit  outputs  can 
pass  this  experiment.  A  similar  structure  was  proposed  by  Kleene  [13]  to  implement  an 
arbitrary  definite  system.  More  precisely,  let  s  =  p  •  k  and  define  next  as 


nextfz,  z) 


z«-p.(*-i),  p-  {k  -  1)  <  1  <  p-  k 
Zi+p,  1  <  *  <  P  •  (*  -  1) 


(2) 


Partition  z  into  a  sequence  of  vectors  [a],  ...,£*]  where  z,  =  . . . ,  z,.p)  and  define 

out  as 

out(z)  =  FinalOut{q ,  [z*j, . . . ,  zk ]) 

for  any  choice  of  q  £  Q.  These  functions  are  extended  monotonically  by  defining  next(z ,  x) 
according  to  Equation  2  and  letting  out  be  any  monotonic  extension.  It  can  be  seen  that  for 
any  sequence  a  =  [c^, . . . ,  a*]  6  $*,  we  have  =  at  J,  the  jth  element  of 

vector  a,,  and  hence  SimOut(a)  =  FinalOut{q,  a) .  Therefore,  the  simulation  experiment 
is  nontrivial. 


*  m *  ‘ 
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Figure  4:  Universal  Implementation  of  a  fc-Definite  System 

Next,  suppose  .M  is  not  fc-definite  for  any  value  of  k.  We  use  an  adversary  argument  to 
show  that  no  nontrivial,  black-box  experiment  for  this  specification  can  also  be  effective. 
Assume  that  there  is  some  nontrivial  simulation  experiment  in  which  fewer  than  k  CYCLE 
commands  occur  without  an  intervening  ERASE  command,  for  some  value  k.  Since  the  ex¬ 
periment  is  nontrivial,  there  must  be  a  circuit  C  =  (s,  next,  out)  and  monotonic  extensions 
of  next  and  out  that  produce  an  acceptable  result  for  the  experiment.  We  will  construct  a 
circuit  C1  =  (s' ,  next' ,  out')  that  does  not  implement  X.  However,  we  can  define  monotonic 
extensions  of  next'  and  out'  such  that  by  defining  SimOut'  in  a  manner  analogous  to  the 
definition  of  SimOut ,  we  have  SimOut'(a)  =  SimOut(a)  for  any  sequence  a  6  ty,  for 
which  l  <  k.  The  simulation  experiment  cannot  possibly  distinguish  C  from  C'  and  hence  is 
not  effective.  This  argument  holds  for  any  value  of  k,  showing  that  there  is  no  finite  upper 
bound  on  the  length  of  a  simulation  experiment  that  can  distinguish  a  correct  circuit  from 
a  defective  one  when  the  specified  system  is  indefinite. 

Circuit  C  is  constructed  as  illustrated  in  Figure  5  by  taking  circuit  C  and  adding  extra 
logic  to  implement  a  “booby  trap”,  i.e.,  logic  that  will  not  affect  the  output  value  until  a 
specific  input  sequence  of  length  k  occurs.  Designing  such  a  booby  trap  is  no  easy  task, 
because  any  state  variables  used  by  the  trap  will  be  set  to  X  whenever  the  user  gives  an 
ERASE  command.  For  an  improper  design  this  could  cause  C'  to  produce  an  X  on  its 
output  under  conditions  when  C  would  not.  Similarly,  the  user  might  attempt  to  expose 
any  traps  by  presenting  inputs  with  some  elements  equal  to  X. 


I 

* 


Figure  5:  Circuit  with  Booby  Trap 


For  the  design  of  C1 ,  let  0  =  [6j, . . . ,  6*]  6  be  some  sequence  such  that  M  has  states 
<71-92  -  Q  for  which  FinalOut{qx,  0)  ^  FinalOut(q2, 0).  Such  a  sequence  must  exist  or  else 
,M  would  be  A:-definite.  Assume  for  simplicity,  that  output  m  differs  for  these  two  cases, 
relabeling  the  outputs  if  required.  The  trap  consists  of  a  shift  register,  where  each  shift 
element  sets  its  output  to  its  input  value  when  the  circuit  input  matches  the  corresponding 
element  of  3  and  clears  the  output  to  0  otherwise.  Consequently,  input  sequence  3  will 
cause  a  1  to  propagate  through  the  shift  register,  forcing  output  m  to  1  when  it  reaches 
the  end.  Any  input  sequence  a  £  0  of  length  less  than  or  equal  to  k  will  cause  the  shift 
register  to  produce  0,  leaving  the  circuit  output  unchanged.  The  behavior  of  the  circuit  for 
input  sequences  a  <  0  will  depend  on  the  initial  state,  and  hence  under  such  conditions 
SimOut'm(a)  —  X.  However,  it  can  be  shown  using  Lemma  3  that  under  these  conditions 
SirnOutm(a)  =  X  as  well. 


The  detailed  design  of  circuit  C'  is  rather  involved  and  hence  is  given  in  Appendix  A  rather 
than  here.  It  is  also  shown  that  for  any  l  <  k,  any  a  6  and  any  i  such  that  1  <  t  <  m: 


SimOut[(a) 


1,  i  =  m  and  a  =  0 

SimOuti(a),  else 


Hence  C  cannot  be  distinguished  from  C  for  any  input  sequence  of  length  less  than  k. 
On  the  other  hand,  since  FinalOutm(q1, 0)  ^  FmalOutm(q2, 0),  we  must  have  either 
SimOut'm{0)  FmalOutm(qi,  0)  or  SimOut'm(0)  ^  Final Outm{q2, 0)  and  hence  by 
Lemma  3,  C  cannot  implement  M. 

□ 
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5  State  Transition  Simulation 


To  verify  circuits  implementing  a  more  general  class  than  definite  systems,  the  results  of 
the  previous  section  imply  that  a  capability  beyond  black-box  simulation  is  required.  At 
the  opposite  extreme,  if  the  user  were  to  completely  specify  the  relation  £ ,  we  could  check 
that  it  satisfies  the  conditions  of  Definition  5  by  exhaustively  simulating  all  states  and 
transitions.  This  approach  would  work  for  any  class  of  systems  and  circuits.  In  practice, 
however,  it  cannot  be  applied  to  circuits  of  significant  size,  because  the  complexity  of 
completely  specifying  and  checking  the  relation  £  would  be  overwhelming.  Exhaustive 
simulation,  however,  provides  a  basis  for  developing  other  simulation  methods  that  over¬ 
come  the  deficiencies  of  black-box  simulation.  It  shows  that  any  circuit  can  be  verified  if 
we  introduce  sufficient  detail  about  the  circuit  structure  into  the  verification  method. 

5.1  The  Assertion  Method 

We  would  prefer  to  introduce  as  little  information  as  possible  about  the  circuit  structure 
into  the  verification.  Toward  this  goal  we  will  develop  a  notation  similar  to  the  Floyd-Hoare 
assertion  method  of  program  verification,  along  with  an  associated  simulation  methodology 
for  testing  assertions. 

Definition  11  A  circuit  assertion  is  a  set  of  four  predicates: 

P{z):  a  precondition  on  the  state  variables,  P:B‘  — ►  {true,  false}. 

I(x):  a  condition  on  the  input  variables,  I:  Bp  — ♦  {true,  false}. 

N(z):  a  postcondition  on  the  state  variables,  N:B‘  — >  {true,  false). 

O(y):  a  postcondition  on  the  output  variables,  0:Bm  —*  {true,  false}. 

A  circuit  assertion  is  denoted  by  an  equation  of  the  form  the  form  P{  I  }N  A  O. 

Definition  12  A  circuit  satisfies  assertion  P{  I  }N  A  O  if  N[next{x,z)\  and 
0{out{next[x,z))\  hold  for  all  z  6  B*  and  x  G  Bp  such  that  P(z)  and  I{k)  hold. 

Given  a  set  of  circuit  assertions,  verifying  a  circuit  requires  two  proofs — that  any  circuit 
satisfying  the  set  of  assertions  must  implement  the  specification,  and  that  the  circuit  under 
consideration  satisfies  these  assertions.  Proving  the  adequacy  of  a  set  of  assertions  involves 
showing  that  they  cover  every  transition  in  the  specification  automaton.  At  the  present 


stage  of  this  research,  the  set  of  assertions  and  a  proof  of  their  adequacy  must  be  generated 
manually.  Although  this  places  additional  burden  on  the  user,  experience  has  shown  that 
far  less  manual  effort  is  required  than  with  structural  verifiers. 
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5.2  Testing  Assertions  by  Simulation 

Once  a  set  of  assertions  has  been  devised,  a  simulator  can  verify  that  a  particular  circuit 
satisfies  them.  First,  we  must  structure  the  assertions  in  a  particular  way. 

Definition  13  A  nonvoid  predicate  P:Bn  — »  {true,  f  alse}  is  convex  if  whenever  P{a) 
and  P[b )  hold  for  vectors  a  and  b,  then  P{c)  holds  for  any  vector  c  for  which  c,  G  {a,, 6,} 
for  1  <  i  <  n. 

A  convex  predicate  can  be  expressed  by  a  formula  of  the  form  P[u)  —  L\  A  L2  A  . . .  A  Lk 
where  each  L,  is  a  literal  of  the  form  Uj  =  0  or  =  1.  In  general,  any  assertion  can  be 
rewritten  as  a  set  of  assertions  containing  only  convex  predicates. 

Definition  14  For  convex  predicate  P(u)  defined  over  elements  of  Bn,  the  vectcr  up  G  Tn 
is  defined  as 

l,  P[a)  =>  a,  =  1 
[HpU  =  {  0,  P(a)  =>  aj  =  0 
X ,  else 


For  a  predicate  expressed  as  a  conjunction  of  literals,  the  corresponding  vector  is  obtained 
by  setting  each  element  appearing  in  a  literal  to  its  specified  value,  and  all  other  elements 
to  X.  This  vector  is  analogous  to  the  cubical  representation  of  a  product  term  in  a  Boolean 
expression  [20]. 

Proposition  4  For  convex  predicate  P{u)  and  vector  a  G  Bn,  P(a)  if  and  only  if  up  <  a. 

Proof:  First,  assume  that  P(a)  holds.  For  the  vectors  to  be  ordered  uP  ^  a,  there  must 
be  at  least  one  element  i  such  that  [up]<  =  This,  however,  would  violate  Definition 
14,  and  hence  up  <  a. 

On^the  other  hand,  assume  up  <  a  for  some  a  G  Bn.  Let  b  G  Bn  be  a  vector  such  that 
P(b)  holds.  The  following  procedure  constructs  a  sequence  of  vectors  6°,  61, . . . ,  6n,  such 
that  b  —  b°,  a  —  bn,  and  P(6')  holds  for  0  <  t  <  n.  From  this  we  can  conclude  that  P(a) 
holds.  For  1  <  i  <  n  each  element  j  of  vector  6’  defined  as 


= 


b:  ’ 


3  #  * 
3  =  * 
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The  proof  that  each  vector  6 ’  satisfies  P{b')  proceeds  by  induction  on  i.  Since  6°  =  b  it 
clearly  holds  for  the  basis  case.  Assuming  6,_1  satisfies  P(6'-1),  observe  that  6*_1  7^  6' 
only  if  di  =  ^6‘-1  and  [up],  =  X.  There  must  be  some  vector  d  £  Bn  such  that  P{d)  and 
dx  =  or  else  [up],  would  equal  6J_1.  By  convexity,  P[b')  must  hold,  because  each 

element  of  b'  equals  an  element  of  d  or  an  element  of  b'~l. 

□ 

This  result  shows  that  a  convex  predicate  can  be  represented  by  a  single  cube. 

Theorem  2  For  convex  predicates  P,  I,  N,  and  O  if  zf?  <  next(zp,  f/)  and  yb  < 
out(next(zp ,  xj))  for  any  monotonic  extension  of  circuit  functions  next  and  out,  then  the 
circuit  satisfies  assertion  P{  I  }N  A  O. 

Proof.  Suppose  zfi  <  next(zp,  £;).  By  Proposition  4,  any  vector  z  £  B’  for  which  P(z) 
holds  must  satisfy  zf>  <  z.  Similarly,  any  vector  x  £  Bp  for  which  /(f)  holds  must  satisfy 
£j  <  x.  Therefore,  the  monotonicity  of  next  implies  that 

z~n  <  next{zp,xi )  <  next(z,x) 

and  N[next(x,  z)}  holds  by  Proposition  4. 

Similarly,  when  yb  <  out(next(zP,xj))  the  monotonicity  of  neit  and  out  imply  that 

2/0  <  out(next(zp,  f/))  <  out(next(z,  z)) 
and  hence  0[out{next[x,  z))}  holds. 

□ 

This  theorem  indicates  a  straightforward  procedure  to  test  that  a  circuit  satisfies  an  as¬ 
sertion  with  convex  predicates.  Following  an  ERASE  command,  use  SET  commands  to  set 
all  state  variables  for  which  [fp],  ^  X  to  the  appropriate  values.  Then  give  the  command 
CYCLE(f/)  to  simulate  the  prescribed  action.  Finally,  use  OBSERVE  commands  to  check 
that  Zi  =  [ijsrji  for  all  i  such  that  [£#]<  #  X,  and  an  OUTPUT  command  to  check  that 
2/o  <  out{z). 

6  Performance  Considerations 

Up  to  this  point,  we  have  considered  only  whether  verifying  a  circuit  by  simulation  was 
at  all  possible.  The  resulting  verification  methods  were  not  at  all  efficient.  For  example, 
brute  force  application  of  black-box  simulation  to  verify  a  fc-definite  system  with  m  inputs 
requires  simulating  2km  patterns.  Clearly,  this  is  practical  only  for  small  values  of  k  and  m. 
In  general,  the  circuit  verification  problem  is  NP-hard  as  measured  in  the  size  of  the  circuit 
and  the  specification.  However,  several  techniques  reduce  the  complexity  to  manageable 
levels  for  a  large  class  of  circuits. 


6.1  Input  Weakening 


The  logic  value  X  can  be  used  to  indicate  a  “don’t  care”  (or  more  properly  “shouldn’t 
care”)  condition  when  the  circuit  behavior  being  tested  should  not  depend  on  that  par¬ 
ticular  input.  This  allows  us  to  simulate  the  effects  of  a  number  of  Boolean  sequences 
with  a  single  ternary  sequence,  leading  at  times  to  a  dramatic  reduction  in  the  simulation 
complexity.  This  technique  is  called  “input  weakening”,  because  it  involves  reducing  the 
information  content  of  the  simulation  sequences.  Monotonicity  guarantees  that  if  the  re¬ 
sulting  response  on  some  output  is  0  or  1,  then  all  stronger  sequences  would  give  the  same 
response. 

For  example,  consider  a  fc-bit  long,  1-bit  wide  shift  register.  Brute  force,  black-box  simu¬ 
lation  requires  simulating  2*  patterns  of  the  form  [ai,  a^, .  ■  ■ , a*],  each  time  checking  that 
the  final  output  equals  a\.  Since  the  output  of  the  shift  register  should  depend  only  on  the 
first  value  in  the  sequence,  we  can  set  the  input  to  X  for  the  remainder  of  the  simulation. 
This  reduces  the  number  of  simulation  sequences  to  two:  (l,  X, . . . ,  X]  and  [0,  X, . . . ,  X], 
without  compromising  the  rigor  of  the  simulation.  Generalizing  this  to  a  shift  register  of 
width  m,  a  total  of  2m  sequences,  each  of  length  k ,  suffices,  consisting  of  a  pair  to  test 
each  bit  of  the  data  word.  Compared  to  the  ad  hoc  methods  most  designers  use  to  validate 
shift  registers  (e.g.,  simulate  a  randomly  chosen  input  sequence),  the  proposed  method 
provides  better  results  at  a  comparable  cost. 

To  develop  this  idea  formally,  we  define  a  covering  set  as  a  set  of  ternary  sequences  that 
include  all  possible  Boolean  sequences  of  a  given  length. 

Definition  15  A  set  A  C  ^  is  a  covering  set  for  if  to  every  f3  E  there  corresponds 
some  a  E  A  such  that  a  <  /?. 

Theorem  3  For  a  covering  set  A  of  if  SimOut(a)  =  FinalOut(q,  (3)  for  all  a  E  A, 
all  (3  E  $jt  such  that  a  <  (3,  and  all  q  E  Q,  then  the  simulated  circuit  C  implements 
specification  M. 

Proof:  By  the  monotonicity  of  SimOut,  if  a  <  (3,  then  SimOut(a)  <  SimOut{(3).  How¬ 
ever,  the  assumption  that  SimOut(a)  =  FinalOut(q,  /3)  implies  that  SimOut(a)  E  Bm , 
and  hence  SimOut((3)  =  FinalOut{q,  (3).  Thus,  the  conditions  required  by  Lemma  2  hold, 
and  C  implements  M. 

□ 

Input  weakening  can  also  be  applied  in  transition  simulation.  In  fact  the  simulation  se¬ 
quences  arising  from  the  assertion  method  already  utilize  this  technique.  If  convex  predi¬ 
cate  P  places  no  conditions  on  element  i  of  a  vector,  then  corresponding  variable  is  set  to 
X  in  the  simulation. 
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6.2  Symbolic  Simulation 


At  times  we  cannot  avoid  the  complexity  caused  by  the  large  number  of  possible  input 
combinations  that  might  be  applied  to  a  circuit,  all  of  which  might  be  relevant  to  the  values 
of  the  outputs.  For  these  cases,  we  propose  symbolic  simulation  to  reduce  the  number  of 
patterns  simulated.  A  symbolic  simulator  [5]  resembles  a  conventional  logic  simulator, 
except  that  the  input  sequences  can  contain  Boolean  variables  in  addition  to  the  constants 
1  and  0.  During  simulation  the  values  of  the  circuit  state  and  output  are  Boolean  functions 
of  the  variables  occurring  in  the  input  sequence.  A  symbolic  simulator  represents  and 
manipulates  these  functions  explicitly.  The  worst-case  behavior  of  such  a  program  gives 
no  better  performance  than  exhaustive  simulation  by  a  conventional  simulator.  However, 
good  Boolean  manipulation  algorithms  often  lead  to  far  better  results.  To  implement 
the  verification  methodologies  described  in  this  paper,  a  symbolic  simulator  must  be  able 
to  manipulate  functions  over  the  three-valued  domain  {0,1,  X}.  The  symbolic  simulator 
MOSSYM  [5]  solves  this  problem  by  representing  every  circuit  variable  by  a  pair  of  Boolean 
functions,  generalizing  the  encoding  of  three  possible  values  by  two  bits. 

A  symbolic  simulator  can  verify  an  m-input,  fc-definite  system  by  simulating  a  single 
sequence  of  length  k,  with  each  input  pattern  consisting  of  m  Boolean  variables  to  represent 
all  possible  input  values.  The  resulting  output  functions  will  be  symbolic  representations  of 
the  circuit  outputs  for  every  possible  input  sequence  of  length  k.  These  can  then  be  tested 
for  equivalence  with  functions  generated  from  the  system  specification.  As  an  example  of 
verification  by  symbolic  simulation,  the  above-mentioned  shift  register  would  be  verified 
by  simulating  the  sequence  of  variables  [01,02,. .  .,a*]  and  testing  the  final  output  for 
equivalence  with  the  function  a\.  Efficient  symbolic  manipulation  will  exploit  the  fact  that 
the  variables  shifting  through  the  register  do  not  interact.  Hence  a  symbolic  simulator  can 
automatically  take  advantage  of  the  same  properties  that  allow  input  weakening.  Symbolic 
simulation  can  also  handle  cases  for  which  input  weakening  does  not  apply.  For  example, 
MOSSYM  was  able  to  verify  a  16-bit  nMOS  adder  using  less  than  10  minutes  of  CPU  time  on  a 
Digital  Equipment  Corporation  VAX-11/780.  In  contrast,  its  more  traditional  counterpart 
MOSSIM  II  [4]  would  require  an  estimated  648  years  using  exhaustive  black-box  simulation. 

The  capabilities  of  symbolic  simulator  can  also  be  exploited  in  verifying  indefinite  systems. 
Rather  than  testing  a  large  number  of  assertions  with  predicates  containing  terms  of  the 
form  v  =  0  or  v  =  1,  the  program  would  test  a  smaller  set  of  assertions  containing 
predicates  of  the  form  v  =  a  where  a  is  a  symbolic  variable.  That  is,  a  symbolic  simulator 
can  test  assertions  having  the  form  of  universally  quantified  formulas  rather  than  single 
propositions.  Furthermore,  it  does  not  require  the  predicates  to  be  convex. 

Although  a  symbolic  simulator  gives  the  user  a  far  more  abstract  view  of  circuit  behavior, 
it  has  no  fundamental  power  beyond  that  of  an  ordinary  logic  simulator.  Any  information 
that  symbolic  simulation  provides  could  also  be  obtained  by  exhaustively  simulating  the 
set  of  patterns  generated  by  enumerating  all  combinations  of  0  and  1  for  the  Boolean 


ADDR0 


Figure  6:  Static  RAM  Circuit 


variables. 


7  Memory  Verification  Example 


To  demonstrate  the  methodology  on  a  more  significant  task  for  hardware  verification, 
consider  the  static  random-access  memory  (RAM)  illustrated  in  Figure  6.  The  assertions 
required  to  verify  this  circuit  will  be  presented  in  a  series  of  steps,  each  introducing  new 
notation  and  discussing  the  reasoning  behind  it.  Despite  these  extensions  to  the  notation, 
the  underlying  principle  remains  that  of  state  transition  simulation. 

This  circuit  holds  n  =  2m  bits,  where  each  memory  cell  z,  such  that  0  <  z  <  n,  consists  of  a 
feedback  path  containing  electrical  nodes  B,-  and  B,  along  with  a  pair  of  access  transistors 
[10].  As  a  shorthand,  the  predicate  Store(i,v)  expresses  the  fact  that  value  v  £  {0,1}  is 
stored  in  memory  cell  z: 

Store(i,v)  =  Bj  =  v  A  =  ->u. 

The  input  lines  ADDR,,  for  0  <  j  <  m,  select  a  particular  memory  cell.  When  WRITE  =  1, 
the  value  of  DIN  is  written  into  the  selected  memory  cell.  As  shorthand,  this  operation  is 
expressed  by  a  predicate 

Writc{i,v)  =  WRITE  =  1  A  DIN  =  v  A  V(0  <  k  <  m)[ADDRt  =  z'k] 

where  z'k  indicates  the  kth  bit  in  the  binary  representation  of  z.  When  WRITE  =  0,  the 
value  stored  in  the  selected  memory  cell  is  produced  as  output  on  DOUT.  This  operation 


is  expressed  by  the  predicate 

Read(i)  =  WRITE  =  0  A  V(0  <  k  <  m) '  ADDR*  =  i*j. 

Although  few  additional  details  of  the  circuit  design  are  needed  for  verification,  correct 
circuit  operation  depends  on  the  fact  that  the  control  lines  WORD,  equal  0  when  the  circuit 
is  quiescent,  for  0  <  r  <  y/n.x  Without  this  property,  the  access  transistors  for  more  than 
one  cell  in  a  column  could  be  turned  on,  causing  undesirable  interactions.  This  fact  is 
formulated  as  a  system  invariant 

Inv  =  V(0  <  r  <  v/n)[WORDr  =  0], 

The  invariance  of  this  condition  is  expressed  by  a  single  assertion: 

true  |  true  j  Inv 

That  is,  following  any  memory  operation,  the  word  lines  will  return  to  a  quiescent  con¬ 
dition.  Once  the  assertion  has  been  established,  the  invariant  Inv  can  be  assumed  as  a 
precondition  in  all  other  assertions.  Most  circuits  require  some  form  of  system  invariant 
expressing  conditions  about  the  control  logic  that  can  be  assumed  true  at  the  beginning 
of  every  input  cycle.  Devising  the  invariant  requires  a  combination  of  analysis  and  ex¬ 
perimentation.  An  insufficient  system  invariant  will  become  immediately  apparent  during 
subsequent  simulations,  because  output  or  state  variables  that  should  have  Boolean  values 
will  equal  X. 

The  remaining  assertions  simply  express  the  operation  of  a  memory.  First,  for  all  v  £  {0,  1} 
and  for  all  t  such  that  0  <  :  <  n,  an  assertion  states  that  writing  v  into  location  »  must 
cause  v  to  be  stored  in  cell  i: 

Inv  |  Write(i,  v)  }  Store(i,v). 

Second,  for  all  v  £  {0, 1}  and  for  all  t  and  j  such  that  0  <  i,j  <  n  and  i  ^  j,  an  assertion 
states  that  writing  into  location  j  does  not  affect  the  value  in  cell  »: 

Inv  A  Store(i,  v)  j  Writc{j,  X)  }  Storc(i,v).  (3) 

Third,  for  all  v  £  {0, 1}  and  for  all  i  such  that  0  <  i  <  n,  an  assertion  states  that  reading 
location  t  causes  its  value  to  appear  on  the  output: 

Inv  A  Store(i,v)  j  Read{i)  j  DOUT  =  v. 

Finally,  for  all  v  £  {0, 1}  and  for  all  i  such  that  0  <  t  <  n,  an  assertion  states  that  reading 
a  value  from  any  location  should  have  no  effect  on  the  value  stored  in  location  i: 

Inv  A  Store(i,  v)  {  WRITE  =  0  }  Sfore(t,  t>).  (4) 

1  A  memory  circuit  is  generally  configured  as  a  square  array  of  memory  cells  with  m/2  of  the  address  bits 
selecting  a  row  and  the  remaining  selecting  a  column.  Hence  there  are  \/n  rows. 


The  above  equations  represent  a  total  of  2 n2  -t-  6n  -f  1  assertions.  The  number  can  be 
further  reduced  by  exploiting  input  weakening  for  the  cases  covered  by  Equation  3.  That 
is,  for  an  address  i  with  bit  representation  (z’o, . . . ,  all  addresses  j  such  that  j  i  are 

covered  by  vectors  of  the  form  (X, . . . ,  X,  -> i* ,  X, . . .  ,  X)  for  0  <  k  <  m.  Thus,  Equation  3 
can  be  replaced  by  the  following  set  of  assertions  for  v  €  {0, 1},  0  <  t  <  n,  and  0  <  k  <  m: 

Inv  A  Store(i,v)  j  WRITE  =  1  A  ADDR*  =  }  Store(i,v).  (5) 

This  reduces  the  total  number  of  assertions  to  2n  log  n  4-  6n  +  1.  In  practice,  many  memory 
circuits  would  yield  false  negative  responses  for  some  of  the  assertions  of  Equations  4  and 
5.  The  simulation  of  an  assertion  that  causes  the  word  line  of  a  memory  cell  to  be  set  to  X 
would  most  likely  corrupt  the  value  stored  in  the  cell.  With  more  care,  however,  a  set  of 
assertions  can  be  devised  that  avoid  this  problem  while  maintaining  the  0[n  log  n)  bound 
on  the  total  number  of  patterns  to  be  simulated. 

Considering  that  even  a  minimal  validation  of  a  memory  circuit  requires  simulating  Q(n) 
patterns  (e.g.,  read  and  write  every  memory  location),  simulating  0{n  log  n)  patterns  seems 
a  very  reasonable  price  to  pay  for  rigorous  verification.  The  efficiency  of  this  verification 
results  from  an  extreme  form  of  input  (and  state  variable)  weakening.  The  verification 
isolates  each  memory  location,  proving  that  it  can  be  written  and  read  properly,  and  that 
operations  on  other  memory  locations  do  not  corrupt  its  stored  value.  During  each  test, 
those  memory  locations  not  under  consideration  are  set  to  X.  Should  the  circuit  contain 
an  undesirable  pattern  sensitivity,  at  least  one  of  the  tests  will  fail  with  an  output  or  state 
variable  equal  to  X  that  should  equal  0  or  1. 

Devising  a  simulation  sequence  to  verify  this  memory  requires  paying  a  significant  amount 
of  attention  to  the  details  of  the  circuit  design,  especially  when  trying  to  minimize  the  num¬ 
ber  of  assertions.  In  contrast  to  black-box  simulation,  the  resulting  simulation  sequence 
is  highly  circuit  dependent.  Compare  this  effort,  however,  to  that  required  by  other  ver¬ 
ifiers.  For  structural  verification  the  user  would  be  required  to  specify  the  operation  of 
all  aspects  of  the  circuit  including  the  address  decoders,  bit  lines,  sense  amps,  and  control 
logic.  These  specifications  would  require  a  circuit  model  that  can  express  such  effects  as 
bidirectional  transistor  behavior,  ratioed  circuits,  and  precharged  logic.  By  comparison, 
behavioral  verification  seems  quite  straightforward. 

8  Discussion 

This  paper  has  outlined  a  method  for  applying  three-valued  logic  simulation  to  the  task  of 
hardware  verification.  Complex  circuits  can  be  rigorously  verified  given  only  information 
about  the  desired  input-output  behavior,  and  possibly  some  information  about  the  circuit 
state  variables. 

Multi-valued  modeling  provides  the  fundamental  mechanism  by  which  a  circuit  can  be 


verified  knowing  little  about  its  internal  structure.  The  requirements  placed  on  the  simu¬ 
lator  to  support  verification  are  fairly  mild.  Most  contemporary  logic  simulators  provide 
a  value  X  to  avoid  the  need  to  find  an  initial  Boolean  state  of  the  circuit  that  does  not 
cause  oscillations  [12].  Although  an  explicit  ERASE  command  may  not  be  provided,  it 
can  easily  be  implemented,  or  the  same  result  can  be  obtained  by  simply  restarting  the 
program.  The  monotonicity  requirement  simply  expresses  the  desirable  property  that  in 
the  presence  of  X  values,  the  simulator  should  not  set  an  output  or  state  variable  to  0 
or  1,  when  this  would  not  have  occurred  had  some  of  the  X’s  been  0  or  1  instead.  Any 
reasonable  implementation  satisfies  this. 

The  resulting  simulation  sequences,  however,  differ  greatly  from  those  commonly  used 
by  circuit  designers  during  informal  validation.  In  particular,  the  state  of  the  circuit  is 
frequently  set  to  all  X’s  so  that  any  accidental  sequential  dependencies  will  be  detected. 
During  most  sequences,  only  a  small  number  of  state  or  input  variables  are  set  to  Boolean 
values,  and  attention  is  focused  on  the  effect  these  values  have  on  the  output  or  new 
circuit  state.  Any  accidental  dependencies  on  other  state  or  input  variables  will  manifest 
themselves  as  X’s  on  output  or  state  variables  that  are  expected  to  have  Boolean  values. 
Most  logic  simulators  have  not  been  designed  for  this  style  of  simulation.  Many  use 
pessimistic  methods  of  computing  the  effect  of  X  values,  causing  them  to  produce  X’s 
where  it  can  be  shown  that  the  true  results  should  be  Boolean  values.  Such  a  simulator 
provides  too  dull  a  tool  for  formal  circuit  verification,  giving  many  false  negative  responses. 
With  greater  care,  however,  simulators  can  be  designed  to  provide  more  accurate  and 
efficient  modeling  of  X’s. 

This  methodology  demonstrates  several  worthwhile  simulation  practices  that  could  be  ap¬ 
plied  even  when  formal  verification  is  not  sought.  For  example,  typical  simulation  runs 
consist  of  many  pattern  sequences  where  the  behavior  of  the  circuit  should  not  depend  on 
the  relative  ordering  of  these  sequences.  Preceding  each  pattern  sequence  by  an  ERASE 
command  would  help  uncover  any  accidental  pattern  sensitivities.  As  the  memory  verifi¬ 
cation  example  showed,  a  simulator  can  uncover  more  potential  errors  if  the  user  can  focus 
on  small  regions  of  the  circuit  at  a  time,  setting  to  X  those  input  and  state  variables  that 
should  not  affect  the  behavior  in  this  region.  A  common  practice  followed  by  circuit  de¬ 
signers  today  is  to  simulate  an  enormous  number  of  patterns,  possibly  consuming  weeks  of 
CPU  time,  hoping  that  brute  force  will  uncover  any  error.  By  following  a  more  disciplined 
methodology,  shorter  simulation  runs  could  be  devised  that  yield  more  reliable  results. 


A  Design  of  Circuit  C 


This  appendix  documents  the  design  of  a  circuit  that  cannot  be  distinguished  from  a 
circuit  that  implements  specification  M  for  any  simulation  sequence  of  length  less  than  k, 
as  required  in  the  proof  of  Theorem  1.  vVe  assume  in  this  design  that  0  is  some  sequence 
[6i,  ...,&*]€$*  such  that  FinalOutm(qi,  0)  ^  FinalOutm(q2, 0)  for  two  states  q\,qi  €  Q. 
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Lot  s'  —  $  —  Ic.  We  will  define  monotonic  versions  of  the  functions  next'  and  out1  to  be 
used  by  the  simulator  directly.  The  circuit  functions  are  then  defined  by  restricting  the 
arguments  to  be  Boolean  values.  Referring  to  Figure  5  the  shift  register  elements  in  the 
booby  trap  each  have  two  sets  of  inputs:  a  single  data  input  t  and  a  set  of  control  inputs 
a.  For  vector  b  £  Bp,  define  the  function  of  a  shift  register  element  SpT  x  Tp  — ►  T  as 

t,  a  =  b 

0,  a  <  6  or  £  =  0  (6) 

X,  a  <  b  and  t  ^  0 

That  is,  the  input  data  is  shifted  to  the  output  when  the  control  inputs  match  those  given 
by  vector  b.  The  output  is  cleared  to  0  when  at  least  one  control  input  differs  from  the 
corresponding  element  of  b  but  does  not  equal  X.  To  satisfy  monotonicity,  we  adopt  the 
convention  that  whenever  a  <  b  the  output  equals  0  only  if  the  data  input  equals  0,  i.e., 
it  does  not  matter  whether  the  input  is  shifted  or  the  output  is  cleared,  and  equals  X 
otherwise. 


The  next  state  function  for  circuit  C'  is  defined  as 

nexti  ((«!,. .  .2,),  z),  i<s 
next\{z,  x)  =  6^(1,  x),  i  =  s  +  l 

<5j,  '{zi-i,  x)  s+2<i<s+k 


The  output  function  is  defined  as 


out'^z,  f)  = 


outi((zu...,z,),x), 


i  <  m 


z,+k  V  outm{{zi,..  .,z,),x),  i  —  m 
where  the  V  is  extended  monotonically  as  in  Equation  1. 


(7) 


(8) 


To  prove  that  circuit  C  behaves  as  claimed,  we  require  the  following  property  about  the 
value  produced  by  the  shift  register  for  a  given  input  sequence. 


Lemma  4  For  any  l  <  k  and  any  a  £  'Ifi, 


SimState')+k(a)  — 


1,  a  =  p 
0,  a  £  0 
X,  a  <  0 


Proof:  We  will  show  by  induction  on  i  that  for  any  /,  i  such  that  1  <  /  <  i  <  k,  if  we 
consider  any  sequence  a  £  then 


SimState'i+i(a) 


1,  a  =  [6i, . . .  6,] 
’  0,  a  ±  [6,,. .  .6,] 
X,  a  <  [6i , . . .  6,  j 


(9) 


The  statement  of  the  lemma  then  holds  by  letting  i  =  k. 


First,  suppose  i  =  1,  in  which  case  either  a  =  e  whereby  a  <  b jj  and  SimState'^^a)  =  X, 
or  a  =  [a*i ]  for  some  ax  E  Tp,  whereby  SimState'3+l(a)  =  <5^(1,  ai).  Comparing  equation 
6  with  t  =  1  to  equation  9  we  see  that  the  desired  condition  holds. 

Now  assume  that  equation  9  holds  for  some  value  i.  Let  a  =  a1  ■  ai+ 1  be  a  sequence  where 
a' E  ifi  and  l  <  i.  Consider  the  ways  a  can  relate  to  the  sequence  [6j, . . . ,  6,+1]  in  Equation 
9. 

Equality  can  hold  only  if  /  =  i  and  both  a1  —  and  ai+1  =  6,+j.  Combining 

equations  6,  7,  and  9  for  this  case  we  get 

SimState',+i+1{a)  =  SE.+i  (SimState',+i{a'),  at+x)  =  ^.+1(l,^+i)  =  1- 

Incomparability,  i.e.,  a  ■£  [6j, . . . ,  bi+ 1]  can  hold  only  if  either  a(+1  ■£  6,+1  ora'  ^  [6, . . . ,  6,]. 
In  the  first  case  we  have 

S imS tate'3+i+1(a)  =  <5ji+l  {SimState'3+i{a'),  al+l)  =  6^+i(t,al+1)  =  0. 

In  the  second  case  we  have 

SimState'3+l+l{a)  =  6it+i{SimState'3+i{a'),al+l)  =  <5j+i (0,  aI+1)  =  0. 

The  sequences  may  be  ordered  a  <  [6j, .  . . ,  6,-+l]  only  if  either  a'  <  [b, . . . ,  6,]  and  aI+1  < 
bi+ 1,  in  which  case 

5 imS tate'3+i+l(a)  =  6^+i[SimState'3+i(a'),  a,+1)  =  <5j+i  (X,  a,+i)  =  X, 

or  a'  =  [6, .  . . ,  6,]  and  a(+1  <  6,-+1  in  which  case 

SimState'3+l+l(a)  =  6^+i(SimState'3+i(a'),  a,+1)  =  6s,+i  (1,  a/+1)  -  X. 

Finally,  the  sequences  cannot  be  ordered  a  >  [6l5 . . . ,  6i+1],  because  l  <  i,  and  [61( . . . ,  6,-+i] 
is  maximal. 

□ 


Lemma  5  For  any  l  <  k,  any  a  E  ifi,  and  any  i  such  that  1  <  *  <  m: 

1,  i  —  m  and  a  =  0 


SimOut[(a)  - 


SimOuti[a),  else 


Proof:  For  all  cases  except  where  i  =  m  and  a  <  (3,  this  result  follows  from  the  definition 
of  out'  and  from  Lemma  4.  For  a  <  /?,  Lemma  4  tells  us  that  the  shift  register  output 
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■n-;- 


will  equal  X.  However,  given  that  circuit  C  implements  specification  At,  Lemma  3  shows 
that  both  SimOutm(a )  <  FinalOutm{qx,  (3)  and  SimOutm(a)  <  FinalOutm(q2,  (3)  ■  Since 
these  tw’o  values  are  unequal,  we  must  have 

SimOutm(a)  =  SimOut'm(a)  =  X. 


□ 
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